Access control is frequently implemented to control the access of users to resources and/or to make decisions about denying or granting access to those resources. In the context of physical access control, these resources are typically rooms or, more generally, restricted areas guarded by entrances or doors.
The goal of authorization in access control is usually to specify and evaluate/look-up a set of policies that control the access of users to resources, i.e., making decisions about denying or granting access of users to resources. The goal of secure authorization is usually to communicate this decision in a secure manner. The goal of authentication is usually to verify that a user is who the user says he or she is. The focus herein is primarily on authorization.
As shown in FIGS. 1 and 2, an access control system 10 traditionally includes card readers 121, 122, . . . , 12n connected to a centralized controller 14. The card readers 121, 122, . . . , 12n, for example, are typically stationed at doors or other access points to restricted areas. Each of the card readers 121, 122, . . . , 12n reads access cards carried by the users, and the card readers 121, 122, . . . , 12n communicate information read from the access cards to the centralized controller 14. Locks or other entry control devices 161, 162, . . . , 16n at the access points to the restricted areas are subsequently instructed by the centralized controller 14 to either permit or deny access. The card readers 121, 122, . . . , 12n communicate with the centralized controller 14 for every access request. Each of the locks or other entry control devices 161, 162, . . . , 16n usually correspond to one of the card readers 121, 122, . . . , 12n and are located at the same access point.
In many access control systems, such as the access control system 10 shown in FIGS. 1 and 2, neither the card readers 121, 122, . . . , 12n nor the access cards have any appreciable processing, power, or memory themselves. Hence, such card readers 121, 122, . . . , 12n and access cards are usually referred to as passive devices.
By contrast, the centralized controller 14 of the access control system 10 is usually a well designed and sophisticated device with fail-over capabilities and advanced hardware and algorithms to perform fast decision making.
The decision making process of the centralized controller 14 of the access control system 10 is fundamentally based on performing a lookup in a static Access Control List (ACL) 18. The ACL 18 contains static policy based rules (e.g., one rule in the ACL 18 might provide that user X is not allowed entry into room R), which change only when the policy changes (e.g., the ACL 18 might be changed to provide that user X can henceforth enjoy the privileges of room R).
Policies are implemented in a set of rules that governs authorization. The static ACL based policies as mentioned above can be viewed as context-independent policies. In contrast, context-sensitive policies will require a dynamic evaluation of different states of the system including the user's past history of activities. This evaluation is referred to as dynamic authorization.
With the interconnect architecture of FIGS. 1 and 2, and with a reasonable number of users of a protected facility, the access control system 10 using static ACL based policies makes decisions quickly, is reliable, and is considered to be reasonably robust. It may be additionally noted that, in current access control systems, context-sensitive policies typically constitute a small fraction of the total policies governing the operation of the system.
It is expected that buildings and facilities of the future will require increasingly more intelligent physical access control solutions. For example, access control solutions are being provided with the capability to detect such conditions as intrusion and fire. In general, this increased capability implies that such access control solutions should be provided with the ability to specify conditions that are dynamically evaluated, e.g., disable entry to a particular room in case of a break-in, and/or disable entry to a particular room if its occupancy reaches its capacity limit, and/or allow entry to a normal user only if a supervisor is already present inside the room, etc. This increased capability leads to a significant emphasis on the need for dynamic authorization. That is, if context-sensitive policies form a significant part of the access control policies of a facility, then the facility will appear to adapt its access control enforcement in keeping with the changes in the system. Thus, the facility will appear to be more intelligent as compared to facilities having a lesser number of context dependent, access control policies.
Such dynamic authorization can be centrally implemented with the current architecture (FIG. 1 and 2). This centralized implementation will require the context information pertaining to every possible policy to be continuously gathered at the central controller, and upon a request, the controller needs to evaluate this context and needs to arrive at a dynamic authorization decision.
While this process can work for small facilities, such a centralized solution will not scale up well with an increase in the number of users, size of the facility, or complexity of the context-sensitive policies, since progressively more and more information will have to be pushed from various sources to the central controller.
Due to reasons of flexibility and ease of installation and modification, a general purpose network (e.g., an Internet Protocol (IP) network of a facility) is more attractive for an access control solution in comparison with the special purpose dedicated connections between the various devices and the central controller in FIGS. 1 and 2.
As shown in FIG. 3, an access control system 20 using a more generic interconnect architecture may include card readers 221, 222, . . . , 22n connected to a network 24 that is either a wired only network, or a wireless only network, or a mixed wired and wireless network. The network 24 includes controllers 261, . . . , 26n and servers 281, . . . , 28n. The architecture of FIG. 3 is not suitable for the centralized access control system 10 shown in FIGS. 1 and 2. This unsuitability is due to the fundamental dependency on the central controller for every decision, i.e., a system architecture that necessitates a guaranteed reader-to-controller communication for every access decision will not be a good choice for the more generic and flexible interconnect architecture (such as that shown in FIG. 3).
The present application focuses primarily on a decentralized policy evaluation framework for dynamic authorization. Addressed herein are issues of scalability related to dynamic authorization as raised above. The present invention as set out in the claims hereof enables an access control system to leverage a more general purpose network, e.g., the IP network of a facility.
Most work in the domain of facility access control is based on a model having a door D that receives an input I (including user id) from an access card (or some other device carried by an user), that sends information i (where i=f (I)) to a central controller E, and that receives a response R from the central controller E. The response R indicates whether or not access is allowed.
A purely centralized implementation of access control has only one controller E, whereas a slightly more scalable solution that has multiple controllers with different levels or hierarchies and data caching is shown in European Application EP1320012A2.
U.S. Pat. No. 6,570,487 describes an arrangement that is intended to improve the robustness of communications from the doors to the access controllers by providing redundancy of receivers and access controllers (referred to as distributed receivers and distributed access controllers in the literature).
One fundamental problem addressed by work related to access control is that of a secure transmission of the response R from the controller E to the door D rather than of determining the response R per se. It may be recalled that determining the privilege grant content of the response R, i.e., computing what should be the access permission, given a certain door D and input I, is the problem of authorization.
Core Street has described a technique for making the controller E to door D communication more secure by enabling the door D to figure out if the response R is valid, given the input I. Only the controller E can generate the response R and this response can then be made publicly available. That is, the response R cannot be generated by a non-controller E given the input I and previous responses on similar transactions.
Thus, as detailed in U.S. Published Application 20050055567, a barrier to access is provided that includes a controller and at least one administration entity. The controller selectively allows access, and the at least one administration entity generates credentials/proofs. According to the barrier, no valid proofs are determinable given only the credentials and values for expired proofs. The controller receives the credentials and proofs, the controller determines if access is presently authorized, and, if access is presently authorized, the controller allows access.
Document WO2003088166A2 shows how the door D can verify the response R by making use of a one way hash function H (NI) (where NI is dependant on the input I), and an elapsed time interval of which the door D keeps track. A related document WO2005010685 underlines how this strategy can be useful for disconnected doors—where essentially the response R will be carried by the access card.
U.S. Published Application 20030028814 describes a generic microcontroller enabled door reader that can communicate with a smart card. However, its functional architecture uses the card and reader interaction to establish the authenticity of the card and not for authorization.
In the last 10-15 years, significant research efforts have been directed towards coming up with an authorization framework, inclusive of a policy specification language and a well defined authorization model that supports dynamic authorization. To a large extent, these frameworks focus on languages that provide flexibility in specifying role based policies and guarantees unambiguous evaluation (decision) with feasible bounds on the run time, and implicitly assume a centralized implementation of the policy evaluation. These approaches concentrate more on access control as modeled on computer systems in general and not on physical access control in buildings. Consequently, while they underline the need and importance of context-dependent or dynamic evaluation of access control policies, the functional architecture remains centralized and focused on languages that provide flexibility in specifying role based policies and guarantees unambiguous evaluation (decision) with feasible bounds on the run time.
U.S. Pat. No. 6,647,388 discloses that an access request can be used to extract a policy condition and that the policy condition is evaluated to determine if there is sufficient information available to evaluate, to obtain the necessary information if there is insufficient information to reach a proper decision, and then to grant or deny access on the basis of the evaluated information. However, this processing was designed for access control in computer systems in general and, hence, its functional architecture differs from that of the present invention.
Similarly, U.S. Published Application 20050068983 includes a context based access control policy, but is more geared towards software systems where the requesting agent can wait for all the necessary context evaluations to be performed by a separate service module.
U.S. Published Application 20050080838 presents a flexible architecture for dynamic policy evaluation in the context of web-services and is significantly different in the functional modules from the present invention. U.S. Pat. No. 6,014,666, U.S. Published Application 20050132048(A1), U.S. Published Application 20030204751(A1), and U.S. Published Application 20050138419(A1) also discuss similar access control mechanisms in the context of general computer systems and software agents.
There exist applications and standards that use smart cards where per user information is written back to the cards from specific terminals/controllers that they interact with (e.g., MONEO and CEP). An example is the electronic purse. However, these applications concentrate more on security issues and not so much on the context-dependent run-time policy evaluations.
The recent draft of XACML (extensible Access Control Markup Language Version 2.0) under OASIS also addresses access control of general computer systems and focuses on the policy language model. It does include the vision of a distributed access control based on a request response model of many participating entities, and lays down the request/response language protocols for exchanging access control decisions. Thus, it streamlines the terms and their scopes in the context of access control on an internet based network of computing resources, and lays down recommendations of various kinds of data exchanges (and their suggested formats). However, it does not identify any particular functional architecture for decentralized user access control in relation to large facilities.
The present invention solves one or more of these or other problems.